Task: Návrh architektury

Display viewsDisplay views
Návrh architektury je úlohou, v rámci které je na základě důkladné analýzy všech požadavků vytvořena základní architektonická vize vyvíjeného IS/ICT.
Disciplines: Architektura
Expand All SectionsExpand All Sections    Collapse All SectionsCollapse All Sections
CollapsePurpose  
Vždy je nutné mít na paměti, že architektura se neustále vyvíjí a může být v průběhu životního cyklu projektu upravována, např. i na základě testování a hodnocení prototypů navrhovaných řešení. Cílem této úlohy není vytvořit detailní technickou specifikaci systému, ale představit architektonické principy, které by měly být při dalším vývoji respektovány. Informace, které jsou v Popisu architektury specifikovány, slouží jako podklady pro komunikaci architektonické vize s týmem a zákazníkem, či jinými zainteresovanými stranami.
Back to topBack to top
CollapseRelationships  
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    		Optional:
      Outputs
        Back to topBack to top
        CollapseMain Description  
        Jedná se o vymezení technického přístupu k systému, který při respektování všech omezení dokáže vyhovět široké množině požadavků, které jsou na něj kladeny. Odkaz [MMSP, 2011]
        Back to topBack to top
        CollapseSteps  
        Expand All StepsExpand All Steps Collapse All StepsCollapse All Steps
        ExpandIdentifikování cílů architektury  
        Úloha návrh architektury by měla být provedena prostřednictvím několika dílčích kroků, přičemž prvním z nich je identifikace cílů architektury. Architekt by měl neustále spolupracovat se zbytkem projektového týmu a s jeho pomocí identifikovat cíle a požadavky, které by měla architektura řešení podpořit. Pro každou iteraci by měly být vybrány ty, jejichž implementace má nejvyšší prioritu.
        ExpandNalezení omezení architektury  
        Zároveň je nutné identifikovat i omezení, která musí zvolené architektonické řešení respektovat. Specifikováno by mělo být, i jakým způsobem budou tato omezení respektována, přičemž veškerá rozhodnutím musí být řádně odůvodněna. Seznam omezení by měl být pravidelně revidován, aby nedošlo opomenutí žádného z nově identifikovaných faktorů.
        ExpandIdentifikování klíčových abstrakcí a jejich vztahů  
        Dalším z dílčích kroků při návrhu architektury je identifikace klíčových abstrakcí a jejich vztahů. Abstrakce, označované spíše jako tzv. byznys třídy, jsou objekty, na základě kterých je možné modelovat problémovou doménu vyvíjeného softwarového systému a které by měly jednoznačně označovat určitý pojem reálného obchodního světa, jako je například zákazník, objednávka apod. Jedná se tedy v podstatě o vytvoření prvotního konceptuálního (doménového, analytického) modelu tříd. [Arlow, 2008] [Rejnková, 2009]
        ExpandUrčení možností znovupoužití  
        V rámci návrhu architektury by měly být dále identifikovány možnosti znovupoužití již existujících komponent, aplikací apod. Znovupoužití je jednou z důležitých předností softwarového vývoje, kterým je možné ušetřit nejen práci ale i celkové náklady na vývoj. Především objektově orientované jazyky nabízejí řadu prostředků podporujících znovupoužití, nicméně klíčová je z tohoto hlediska zejména identifikace prvků, které je možné opakovaně použít, která je prováděná zkušenými architekty a vývojáři.
        ExpandRozčlenění systému do dílčích částí  
        Dalším z dílčích kroků návrhu architektury je definice přístupu k rozčlenění vyvíjeného systému do dílčích částí, což snižuje komplexnost a usnadňuje jeho vývoj. Kromě vymezení jednotlivých částí je také vhodné navrhnout harmonogram, na základě kterého budou jednotlivé části implementovány a integrovány. Pokud je to nutné, měla být upravena strategie nasazení jednotlivých částí a integrovaného řešení do provozu, která je popisována v Konfiguračním plánu.
        ExpandDefinice rozhraní  
        Dále je nutné definovat veškerá rozhraní, kterými by měl systém disponovat, aby byl schopen komunikovat se všemi požadovanými externími systémy. Nejdříve by v rámci tohoto dílčího kroku mělo proběhnout základní zmapování externích systémů, na které by měla navazovat vlastní definice rozhraní. Jejich popis nemusí být příliš podrobný a měl by být zaměřen především a na informace, které jsou prostřednictvím rozhraní předávány.
        ExpandPopis architektonických mechanismů  
        Součástí návrhu architektury by měla být i identifikace a stručný popis základních architektonických mechanismů, respektive technických služeb, které by systém měl poskytovat, jako je např. řízení transakcí, zálohování dat apod. Nejprve by měl být vytvořen jednoduchý seznam těchto mechanismů, které jsou stručně charakterizovány, bez toho aby bylo popisováno, jakým způsobem budou implementovány. Architektonické mechanismy mohou být určeny buď přímo, na základě zkušeností s určitým typem řešení, nebo mohou být odvozeny z detailních, obvykle nefunkcionálních, požadavků (jako je výkon nebo bezpečnost) na vyvíjené řešení.
        ExpandOvěření vzájemné konzistence prvků architektury  
        Potom, co jsou navrženy jednotlivé prvky architektury, je nutné ověřit jejich vzájemnou konzistenci, přičemž hlavní pozornost by měla být věnována tomu, zda podporují veškeré požadavky na vyvíjený softwarový systém. Závěrečné zhodnocení by mělo být prováděno celým projektovým týmem a mělo by vycházet z vypracovaného Popisu architektury.
        Back to topBack to top
        CollapseKey Considerations  
        Veškerá rozhodnutí, která jsou přijata, by měla být řádně vysvětlena a zaznamenána do pracovního produktu Popis architektury. Je důležité, aby i ostatní členové týmu, kteří mají architekturu realizovat, zvolenému řešení rozuměli a mohli jakékoliv připomínky konzultovat s Architektem.
        Back to topBack to top

        This program and the accompanying materials are made available under the
        Eclipse Public License v1.0 which accompanies this distribution.

        OpenUP Copyright.